home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 12 / Cream of the Crop 12 (Part II) / Cream of the Crop 12 (Part II).iso / OS2 / BLT2_205.ZIP / blt2demo.nfo < prev    next >
Encoding:
Text File  |  1995-09-09  |  4.6 KB  |  115 lines
  1. blt2demo.exe  9-Sep-1995
  2.  
  3. To run the demo, do
  4.  
  5.         C>blt2demo
  6.  
  7. and select from the menu.
  8.  
  9. Test #9 requires an FPU.  Details at CX09.C below.
  10.  
  11.  
  12. ///// Overview
  13.  
  14. All the following are modules run from BLT2DEMO.C (main).
  15. Just startup blt2demo.exe and pick the number of the test to run.
  16. Easy, and pretty fast.
  17.  
  18.  
  19. ///// CX01.C - REINDEX blaze of speed
  20.  
  21. To run cx01.c, just start it up from the command line.  It asks
  22. for run options (display data, thread reindex, size of data set).
  23. Default is for no display of each record, yes thread, and 1 data
  24. record.  You can run up to 10 million data record (less 1), but
  25. that could take an hour.  50,000 is a decent test (about a minute).
  26. Ctrl-C is acceptable if you can't wait for a regular ending.  See
  27. the .c for details.  On this iDX4/100 machine I can reindex 500,000
  28. (half million) in 90 seconds, and 100,000 in 12 seconds.  Fast.
  29.  
  30.  
  31. ///// CX02.C - Use b-tree functionality of Bullet with your own data files
  32.  
  33. For cx02.c, it's similar in operation, but uses no DBF data file.
  34. It's just an example of the external data file mode that let's you
  35. use whatever data file you want (or none at all if the 32-bit key
  36. data item is all the data storage you need).  The key store speed is
  37. not as fast as the reindexing used in cx01.exe, but it still should
  38. be fast enough.  Key access is just as fast.
  39.  
  40.  
  41. ///// CX03.C - atomic INSERT into data/index files
  42.  
  43. For cx03.c, it's similar to the others, but does the data record
  44. store and the key insert in a single.  It can manage up to 512 differnt
  45. files at the same time, with the single call.  Any error in any of the
  46. transaction part has Bullet backout all changes made, automatically.
  47. The 512 files can be in any combination, up to 256 index and 256 data,
  48. even multiple inserts on the same file.
  49.  
  50.  
  51. ///// CX04.C - atomic UPDATE of data/index files
  52.  
  53. For cx04.c, it's...similar to cx03.exe but in addition to performing
  54. inserts, it changes the database with UPDATE_XB.  The action of changing
  55. only the data record results in the key in all related index files to
  56. also be updated.  As with INSERT_XB, UPDATE_XB is transaction-based, so
  57. upon any error during the call, any changes made to the database are
  58. backed-out, and the original state restored.  Since so much more needs
  59. to be done for an update I recommend you limit the number to a few
  60. thousand.  80k updates took 770 seconds here (that still averages over
  61. 100 updates per second).  40k updates took 202 seconds, 20k updates
  62. took 99 seconds, and 10,000 updates to 43 seconds.
  63.  
  64. Be aware that an update does a lot of work: 1) the initial record is
  65. read from the .c program (and modified in memory), 2) and then a call
  66. to Bullet UPDATE_XB for each number you requested.  An update performs
  67. (and in this test case, performs all of the following) 3) a disk read
  68. to get the original record, 4) builds a key based on that, 5) builds a
  69. key based on the modified record, 6) compares them, if different,
  70. 7) deletes the old key, 8) writes out the new key, 9) then writes out
  71. the new data record.  That's for each UPDATE_XB, so think about that
  72. when you enter the "number of records" to do.
  73.  
  74.  
  75. ///// CX05.C - table joins for multiple view of database
  76.  
  77. For cx05.c, it's more of a real-world example than the previous examples
  78. in that it does some really useful work, and doesn't really care how fast
  79. it's done (you already know it's as fast as they come).  This example
  80. creates a 5-file database: two data files and three index files.  After
  81. inserting the data, three different view are done on the database.
  82.  
  83.  
  84. ///// CX06.C - view table with memo file access
  85.  
  86. cx06.exe is based somewhat on cx05, but instead of a second data file,
  87. this example creates and accesses a memo file.  The memo file is pretty
  88. much a free-form, any-size-goes data file.  Any DBF record may contain
  89. a memo file memo, or even several (odd, but possible nevertheless).  The
  90. format used is that of dBASE IV/V.
  91.  
  92.  
  93. ///// CX07.C - file blow-out (1024 simultaneous files open)
  94.  
  95. cx07.c opens up to 1024 files:  512 data and 512 index.  This must be
  96. done in a subdirectory since the root directory is limited to much less
  97. than this.  On an HPFS partition (2MB cache, i486), 1024 files takes about
  98. 20 seconds to compelete.  On a FAT partition (256K cache), it takes
  99. about 45 seconds.
  100.  
  101.  
  102. ///// CX08.C - locks and relocks
  103.  
  104. cx08.c runs through some locking examples, showing how it handles
  105. exclusive and shared region locks.
  106.  
  107.  
  108. ///// CX09.C - REINDEX blaze of speed, with Custom User sortFunction
  109.  
  110. As cx01.c, but uses a custom floating-point sort compare function.
  111. Test #9 requires an FPU, so don't use unless you have a 486DX or later,
  112. or a 387 installed.
  113.  
  114.  
  115.